home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1988 / Aug-Sep 88 / Bug in MPW Pascal ⁄ 08.22.88 ⁄ < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.6 KB  |  68 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  GOLDSMITH1   to LAWRENCE3
  2.  
  3. Item    1277080                         22-Aug-88        08:44
  4.  
  5. From:   A14                             Carnegie Mellon, Rob Chandok
  6.  
  7. To:     MACAPP.TECH$                    MACAPP Tech
  8.         MACDTS                          Macintosh Developer Technical Supt.
  9.  
  10. cc:     ROSENSTEIN1                     Rosenstein, Larry
  11.  
  12. Sub:    Bug in MPW Pascal
  13.  
  14. Well, we just found possibly the worst compiler bug we can imagine (at this
  15. point).  Hopefully, we are just being stupid and it isn't as bad as that.
  16.  
  17. Here are the symptoms:
  18.  
  19. Take a field of an object that is a string[255].  Do two writeln's of it.  The
  20. first writeln comes out as garbage, and the second one is OK.  Code looks like
  21. this:
  22.  
  23. Writeln(myobject.fName); Writeln(myobject.fName);
  24.  
  25. Here is our diagnosis:
  26.  
  27. As everyone knows, the Pascal calling sequence was optimized for quick trap
  28. calls.  Given that, the calling convention for pass-by-value structures over 4
  29. bytes is to pass a pointer on the stack and have the *callee* (not the caller)
  30. copy the value to some temporary storage.
  31.  
  32. While this is all fine, and does speed things up for traps that do not modify
  33. their parameters, it does cause some problems when the value parameter is part
  34. of a relocatable object.
  35.  
  36. Our applications are very segmented, and very large.  So what happened in our
  37. case is that the pointer to a large value parameter field of an object was
  38. pushed onto the stack (for the 1st writeln, in the above example), and the
  39. procedure was called.  However, in our case, the procedure's segment was *not
  40. loaded*, so the heap compacted, the segment loaded, and the writeln continued
  41. with AN INVALID POINTER FOR THE VALUE PARAMETER.  The second writeln worked
  42. because the code segment was still loaded.
  43.  
  44. So, as far as we can tell, we have to go through all our code and look for
  45. places that have fields of objects (larger than 4 bytes) being passed by value,
  46. and write code to copy them into temporary variables before the call.  Sounds
  47. suspiciously like what people write compilers for, and exactly what value
  48. parameters are supposed to do in Pascal.
  49.  
  50. In case you were wondering, the bug did not occur using writelns, and certainly
  51. is not specific to writelns.  It also does not affect trap calls.
  52.  
  53. The MPW pascal compiler DOES NOT DETECT THIS AND FLAG IT!!!!!!!  We believe the
  54. MPW Pascal compiler should detect and warn about this situation, as it is at
  55. least (if not more) dangerous that the "passing fields as VAR parms" problem.
  56.  
  57. It would be nice to hear that this is fixed in Pascal 3.0.
  58.  
  59.  
  60. Rob Chandhok
  61. John Pane
  62. Glen Meter
  63.  
  64. CMU/Computer Science Dept.
  65.  
  66.  
  67.  
  68.